The two areas of online transaction processing (OLTP) and online analytical processing (OLAP) present different challenges for database architectures. In conventional systems, customers with high rates of mission-critical transactions have split their data into two separate systems, one database for OLTP and one so-called data warehouse for OLAP. While allowing for reasonable transaction rates, this separation has many disadvantages including data freshness issues due to the delay caused by only periodically initiating the Extract Transform Load-data staging and excessive resource consumption due to maintaining two separate information systems.
Historically, database systems were mainly used for online transaction processing. Typical examples of such transaction processing systems are sales order entry or banking transaction processing. These transactions access and process only small portions of the entire data and, therefore, can be executed quite fast. According to the standardized TPC-C benchmark results the currently highest-scaled systems can process more than 100.000 such sales transactions per second.
About two decades ago a new usage of database systems evolved: Business Intelligence (BI). The BI-applications rely on long running so-called Online Analytical Processing (OLAP) queries that process substantial portions of the data in order to generate reports for business analysts. Typical reports include the aggregated sales statistics grouped by geographical regions, or by product categories, or by customer classifications, etc. Initial attempts, such as SAP's EIS project, to execute these queries on the operational OLTP database were dismissed as the OLAP query processing led to resource contentions and severely hurt the mission-critical transaction processing. Therefore, the data staging architecture exemplified in FIG. 1 was devised. Here, the transaction processing is carried out on a dedicated OLTP database system. In addition, a separate Data Warehouse system is installed for the business intelligence query processing. Periodically, e.g., during the night, the OLTP database changes are extracted, transformed to the layout of the data warehouse schema, and loaded into the data warehouse. This data staging and its associated ETL process exhibit several inherent drawbacks:                Stale Data: As the ETL process can only be executed periodically, the data warehouse state does not reflect the latest business transactions. Therefore, business analysts have to base their decisions on stale (outdated) data.        Redundancy: The usage of two systems incurs the cost of maintaining two redundant copies of the data. On the positive side, the redundancy allows to model the data in an application specific way: in normalized tables for OLTP-processing and as a star-scheme for OLAP queries.        High expense: Maintaining two separate systems incurs a technical and economical penalty as expenses for two systems (hardware, software, etc) and maintenance costs for two systems and the complex ETL process have to be taken into account.        
It is an object of the present invention to address these drawbacks.